home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0399 / 44 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  1.5 KB
  1. Date: Mon, 30 May 1994 15:26:09 -0400 (EDT)
  2. From: Timothy Miller <millert@undergrad.csee.usf.edu>
  3. Subject: Re: Colour.
  4. To: gem-list@world.std.com
  5. In-Reply-To: <199405301248.OAA04275@blade.stack.urc.tue.nl>
  6. Message-Id: <Pine.3.87.9405301509.A17681-0100000@undergrad>
  7. Mime-Version: 1.0
  8. Precedence: bulk
  9.  
  10.  
  11.  
  12. On Mon, 30 May 1994, Erlend Nagel wrote:
  13.  
  14. > Timothy Miller wrote:
  15. > 
  16. > > Are you sure programmers are going to want to put forth that effort?  
  17. > > It's much easier to just stick together your palette.  How about someone 
  18. > > write a library routine that, given a new palette, sorts them with respect
  19. > > to the palette in place?
  20. > 
  21. > I don't think that just a library routine is good enough for this
  22. > purpose. I think a better solution would be to have colour handling
  23. > installed as a cookie or something like that and only have library
  24. > routines as a mapping. That way the functions can easily be upgraded and
  25. > older programs will be able to use newer implementations of the colour
  26. > handling. I could imagine that earlier versions would not have
  27. > sufficient locking facilities, so that no two programs change the same
  28. > colour at once, but that later ones do. Having a common routine would
  29. > also save a little bit of memory in a multitasking environment.
  30. > 
  31. > Erlend.
  32. > 
  33.  
  34. A cookie would be ok, except that you'd then have to make library 
  35. routines for each of the commonly used compilers for accessing the 
  36. routines, etc.  You'd have to be sure to make this really simple of 
  37. people won't use it.
  38.  
  39.  
  40.